Oracle: first-class command builder + real statement splitting - #390

#3659)

* fix(oracle): run the durability agent through the shared batching mechanics

The durability agent batches its whole recovery operation set into one command
builder and executes it. Oracle's message store handed back the generic
DbCommandBuilder, which emits `@` bind markers and concatenates every statement
into a single command. ODP.NET rejects both -- it has no DbBatch support at all
(CanCreateBatch is false, CreateBatch throws) and will not execute several
statements from one command -- so the agent threw ORA-00933 / ORA-00936 /
ORA-03405 on every sweep and nothing persisted in the inbox or outbox was ever
recovered.

Rather than give Oracle a bespoke execution path, this teaches the shared
batching mechanics about statement boundaries and lets the provider decide what
they mean. DatabaseOperationBatch now marks a boundary before each operation and
executes whatever CompileCommands() hands back. On every provider whose driver
can execute several statements from one command, StartNewCommand() is a no-op,
CompileCommands() returns a single command, and the behaviour is byte for byte
what it was. Oracle returns Weasel.Oracle's OracleDbCommandBuilder, which emits
`:` markers, types parameters through OracleProvider, and splits.

Three things the semicolon-splitting approach would have missed:

- Four operations write more than one statement each (both ReleaseOrphaned
  variants, MoveReplayableErrorMessagesToIncoming, and PersistNodeRecord's
  insert per event). Splitting per operation is not enough, so those now mark
  their internal boundaries explicitly.
- MoveReplayableErrorMessagesToIncoming binds :replayable from two different
  statements. AddNamedParameter finds-or-adds, so it exists once and has to be
  bound to both split commands.
- The same operation hard-coded `@replayable` in its SQL text, which no
  provider-neutral consumer should do. It reads the marker off the builder now.

Also documents the real reason OracleMessageStore.EnqueueAsync is a no-op: it
implements IMessageDatabase directly rather than deriving from MessageDatabase,
so it has no DatabaseBatcher. The durability agent does not use that path.

Adds Pedro Andrade's coverage from #3615, retargeted at the new design and
extended with an end-to-end assertion that the real recovery batch runs against
a real Oracle database -- red-verified as ORA-03405 before this change.

Fixes #3614.

Co-Authored-By: Pedro Henrique Andrade Siqueira <pedroandrade03@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* chore(deps): Weasel 9.19.0

Brings in JasperFx/weasel#390 -- Weasel.Oracle's OracleDbCommandBuilder and the
StartNewCommand()/CompileCommands() statement-boundary hooks on CommandBuilderBase
that the Oracle durability fix is built on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Pedro Henrique Andrade Siqueira <pedroandrade03@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>